No, it is not a bug in fact. For some reason connection to servers 1, 2 and 4 was closed in quick succession. Server restart or some kind of communication break is responsible. Airio in that case disconnects from the server and tries to reconnect within 5 minutes. Such things happen sometimes when Airio runs remotely (on another PC, communicating with the server over Internet), very rarely when running locally.
Well, I'd like to add a few more "standard" features (maybe admin-configurable timetraps similar way speedtraps can be set), clean up some internal inconsistencies. Then it will be time to create in-game state display with update options, starting with filters, adding as much as possible.
Also big thanks for your donation, I've already send you a link to FULL version and I'll generate licence file for you as soon as I know what text (including color codes) it should display.
I just sent you some example configuration files. Generally, when setting up Airio for the first time, I'd suggest the following procedure:
1) After extraction all files from the archive open Airio.con.1.txt and define connection to your server (IP, InSim [not game!!!] port, admin pass).
2) Run Airio.exe, see if connection could be established. If you see system "inicialization error", you probably do not have .NET framework installed. If you see Airio TCP error, then the IP/port combinantion cannot be reached. PASS error means TCP/port exists, but refuses to accept password. This may also be caused by trying to connect Airio to game port instead of insim port.
3) If all runs well, the server is managed with default settings. They are very reasonable, I think, you can test the system without too many restrictions applied.
4) Go through the config files, for a start use CFG and SRV. Read explanations of all items, it should give you a good overview of what is possible. Adjust whatever appropriate, type !rld, see how the change works. Find advanced track/car setting in TCD file...
Good luck!
I really do not know how FIXED option is used. I would say the server then does no reordering, but where does it take the initial order from I do not know. Probably it must be set by the REO packet or something very similar to random order is used. That means you still need to use some communication packet. Another option is manual ordering in the race end (lobby) screen, but that is really cumbersome.
I took a look into LFS External documentation and I'm afraid the option to send requested race order is missing there. I also do not see any option to send your own constructed packet, so I think you're stuck. You need to ask LFS External developers to add the necessary code and the Set_REO_RaceOrder method... 
Well, I do not know the External Library you mention, so I do not know what it allows you to do. If it goes a bit above basic level, it should have a method to send the IS_REO packet. You'd supply array of byte values, specifically player IDs, and it will create the right packet and send it to server.
In case the library just manages the connection for you and leaves out the packet creation, you could use code similar to this one:
You supply player IDs as a byte array and get back fully formed IS_REO packet as byte array, ready for sending. But you cannot use Send_TINY, because that function accepts only one byte as a parameter, not array of bytes. REO is not a TINY packet. (Is there Send_ISP available? You'd need that one.)
Note that you need to send this packet after restart vote was called, but before the grid is formed, that is about the moment when Race Restart shows 2 or 1. Another option is to use fixed grid, but I have no experience with this mode.
So the hardest part is getting player IDs (which are changing after every spectating), sorting them based on some criteria, and capturing the right moment to send the packet. The packet itself is rather simple.
In case the library just manages the connection for you and leaves out the packet creation, you could use code similar to this one:
static public byte[] IS_REO(byte[] PLIDs)
{
byte[] packet = new byte[36];
packet[0] = (byte)packet.Length; // = 36
packet[1] = (byte)Enums.ISP.REO; // = also 36 (by pure chance)
packet[2] = 0;
packet[3] = (byte)Math.Min(PLIDs.Length, 32)
Array.Copy(PLIDs, 0, packet, 4, Math.Min(PLIDs.Length, 32));
return packet;
}You supply player IDs as a byte array and get back fully formed IS_REO packet as byte array, ready for sending. But you cannot use Send_TINY, because that function accepts only one byte as a parameter, not array of bytes. REO is not a TINY packet. (Is there Send_ISP available? You'd need that one.)
Note that you need to send this packet after restart vote was called, but before the grid is formed, that is about the moment when Race Restart shows 2 or 1. Another option is to use fixed grid, but I have no experience with this mode.
So the hardest part is getting player IDs (which are changing after every spectating), sorting them based on some criteria, and capturing the right moment to send the packet. The packet itself is rather simple.
Yes, they've been hectic months indeed. People always come with bright ideas. I have now 2 or 3 preferential things to implement, all of them really nice. But all of them also take many hours to do and twice as much to test and debug. So please calm down a bit concerning the setup GUI, it will really take some time and thinking.
Well, the idea would be to manually set connection data (server IP, port, pass) and then do all setup through admin commands and admin screens. Say, you as an admin (maybe super-admin) type !cfg and see some hierarchy of overall instance settings, showing current state, short explanations and allowing easy change. Same with !srv command, this time working on individual server level. But as you may guess, it will not be easy... It is just an initial idea, it might prove as unworkable, but another principle may appear.
I know of none. LFS shows warning whether you run 2 or more graphical clients or 2 or more dedicated servers. I take it as a warning - ignore it if it was your intention to run 2 servers. I've never had any problems running multiple LFS instances at once.
Well, Scud, I can see who banned you, it was one of our limited admins (aka limads). I cannot say what was the cause, but surely you should be always in some way warned first, told where you're going wrong, and only then banned if necessary. We'll watch the one who banned you a bit closer and also correct his ways if not appropriate. As for the ban itself, it will expire in some 6-8 hours, so let's leave it as it is. In the morning you can connect again. If you experience any more troubles, best way to post them is www.airattack.co.uk site, Club Forums, LFS section.
Hi! Glad to hear!
Right, I realize updating those external configuration files (3 main ones – CFG, TCD, SRV) is cumbersome. Comparison tools surely help a lot, but in case you need to do the update for 2 or more Airio instances it's very boring anyway.
This config problem is closely connected with another one that is bothering me currently: There's no easy way to see current server status, e.g. what checks are actually running (and what settings they use). These matters may depend on several settings and looking them up in configs is not easy.
Naturally the best solution would be to make Airio config completely graphical, right in the game. This would always include all new options, setup changes would be stored temporarily in memory or written to disk into config files.
Well, possible? Surely! Planned? Yes, but in some longer term (several months). Easy? No, not really, because many things need to be considered. Still, for me that is the way to go, rather than creating some external tools...
I'm not sure what it is, I guess some separate tool to set up dedicated LFS server. Well, it would be nice to have something of the sort in Airio too, showing current server state and allowing changes by clicking or typing new values. No doubt it would be nice for those who do not like / commands and config files. This could be part of Airio graphical config, but again it is a question of some later development.
Of course it is cumulative, it could come over several weeks or from several people, I only need to know what target licence the particular donation concerns.
Thanks for all these ideas! I'll surely not forget and I'll try to start building the graphical configration options ASAP, so that at least e.g. the filter settings are easily adjustable. But this includes many considerations...
First the more simple things, tomorrow I'll write a bit more about those ideas.
Well, wrong URI error probably means the address you entered into a configuration file does not have correct recognizable form. Can you post here the error lines from Airio.log file? That would give me a hint what specific item it concerns, and we can see why the entry is not being accepted.
What Bunder shown to you was correct, restricted cars often need time adjustments. However if you're using high restriction, you are basically creating a new car type. For that case the best solution is to define custom cars. Some people use for example UFB = UFR+45% or FZ2=FZR+20% intake air restriction.
Once you define such custom car (in TCD file you'll find the above examples), then you gain virtual new car type. Airio will keep completely separate stats for such car, so that you may have in one instance UFR and UFB cars stats kept separately. You may disallow using unrestricted cars, group custom cars into categories, etc. do anything with them just like with standard LFS cars.
My opinion is that custom cars are one of the best Airio features, not used much though. Check out for example the Ready2Roll GT2 Racing server, there is a GT2 category completely separate from standard GTR cars. Try joining with GTR, see what it says, try using GT2s, see how custom cars are handled and reported, try using some car commands, such as !sb or !pb or !pi once you make a few laps.
Well, wrong URI error probably means the address you entered into a configuration file does not have correct recognizable form. Can you post here the error lines from Airio.log file? That would give me a hint what specific item it concerns, and we can see why the entry is not being accepted.
What Bunder shown to you was correct, restricted cars often need time adjustments. However if you're using high restriction, you are basically creating a new car type. For that case the best solution is to define custom cars. Some people use for example UFB = UFR+45% or FZ2=FZR+20% intake air restriction.
Once you define such custom car (in TCD file you'll find the above examples), then you gain virtual new car type. Airio will keep completely separate stats for such car, so that you may have in one instance UFR and UFB cars stats kept separately. You may disallow using unrestricted cars, group custom cars into categories, etc. do anything with them just like with standard LFS cars.
My opinion is that custom cars are one of the best Airio features, not used much though.
Check out for example the Ready2Roll GT2 Racing server, there is a GT2 category completely separate from standard GTR cars. Try joining with GTR, see what it says, try using GT2s, see how custom cars are handled and reported, try using some car commands, such as !sb or !pb or !pi once you make a few laps. Yes, the (partial) text you see is returned by a PHP script, it is some error probably on the PHP side. Check what external scripts you're using...
The last node where you can leave track when going to pits and the first node where you can join track when leaving the pits are fully configurable. Default Airio TCD file does not contain these definitions – they depend on what you need on individual tracks.
I was doing some tests for KY2 without layout and I believe the following settings are applicable if you consider only the wide white lines (the yellow lines are longer and maybe too restrictive, esp. on pit entry). These settings worked OK for me, both for pitlane entry and exit:
PitEntryNode=428
PitExitNode=574
To setup your own pit entry/exit nodes use these steps: 1) Set OffPath in TCD file to 0 (zero!). Apply the change by !rld. 2) Turn on All Messages for yourself or at least Path check (in personal preferences). 3) Drive slowly from pitlane as close to race path as possible without cutting pitlines. 4) When you see "On the race path", stop, type !node and define the number as PitExitNode under appropriate track in TCD file. 5) Drive slowly on the race path leaving it for the pitlane at the last possible moment. 6) When you see "Off the race path", stop, type !node and define the number as PitEntryNode under appropriate track in TCD file. 7) Try some real pit entry/exit to see if the warnings (always) and penalties (only in race) work correctly.
Yes, I know sometimes a button click results in a strange error, that's why there are the DEBUG messages.
To say the truth I do not know how is a "bad" click possible. But nevermind, I just added index check at appropriate place, so that inexistent button clicks are ignored.First, I really do not know what exactly the little bars show. Obviously they all go to red when someone is timing out. When you yourself are timing out, just one bar goes up. With sufficient height (equal to about 10 seconds) someone times out. However many times the bars were pumping OK, I saw all cars around me and suddenly I timed out or lost connection.
Second, the lagging check is very objective, it depends on car state reported by the server. LFS server reports missing car position packets. If you see "You are lagging" message, it really means the server doesn't know your position for quite a long time (say for 1 s or more). Server doesn't know the position, so other people cannot see you correctly, your car is just moving in the last known direction with last know speed in the Remote. I believe the lagging check uses the most reliable data available.
The correct text should be a very generic "Spectated/kicked for bad joining". This has been changed long time ago when some other joining checks were added to repeated joining. The problem is FM people are using very old MSG.EN file which takes precedence over what is hard-coded into Airio (to support text customization and localization). But I also noticed this obsolete message and consider it misleading, so I'll ask Fail to change at least this one (or simply use the latest EN file).
Ha! I beat you by several hours! Check yesterday's the Airio log and see if that's what you needed.
Hm, this is not yet implemented, but very easy to add into prepared Airio 2.3.4. I guess RName (formerly RegisteredUsers) items could be used for this? Do you agree? If someone is registered (for an event or as someone special) he really can have any nickname and skinname – if he misuses the options, you can just remove him from RName list...
Last edited by EQ Worry, .
Sorry, it took me a while to return to these layout racing matters, but Airio 2.3.4 (not yet available) indeed contains the spectate reason message and also race time with difference to previously scored best, both in chat. Also last lap/split data stay on screen as buttons for review.
You may change the text SPECTATED AFTER FINISH (in MSG fie) to something else you need or consider clearer, however you cannot change placement of the message parts, it will always be NICKNAME : CUSTOM_TEXT.
I asked a PHP expert how he's reading Airio UTF files and if I understood correctly it goes like this: Read lines from start of the file, ignore all empty ones, consider as line 1 the one actually containing some data. In case of PB.txt the first non-empty line would contain USERNAME... This line may be compared to some fixed value in script making sure the file is of correct version, etc.
Ha! Good!
Hi! Good!
1) Penalties are applied only in race; after race, in practice or during qualification they are of no value, so only warning is shown. 2) The settings used look good, I'll use the values for some checks to see why there's no pit entry penalty applied (or at least warning displayed). It could have several reasons (bug, incorrect value).Well, in fact if I understand it correctly, Lapper data (PB.txt) are saved in default codepage of the system where it is running, which can really be anything. In Airio there's UTF-8 directly specified. So, if I remove that specification, maybe we'll get more one-system compatible file. I believe there may be problem though moving that file to system with different codepage – reading some characters just as date/time may fail.
Yes, everyone please be careful if you're using special characters in any of Airio files (MSG, CFG, SRV). After editing using the TC panel these characters will not be recognized correctly. Best way is to edit the files externaly and upload them to 500 (or storm) servers, then apply changes by !rld.
Ah, i see. Well, try to understand why the script returns no data, maybe you'll be able to update it a bit and solve the issue. But when I find a free hour or so, I'll check Lapper's code used for PB.txt save/export and try to mimick it to get 100 percent compatible export file.
Well, I still do not know what problem you have with displaying exported PB.txt (Lapper) data. Wrong characters displayed? No data read? See http://cs.wikipedia.org/wiki/UTF-8#BOM to read what is BOM, it is standard identifying part of UTF-8 encoded files. Does anyone else have problems reading exported PB.txt file? If not, maybe try adapting your PHP script to read UTF-8 file and not (probably) binary data.
As Zero already pointed out, you have 3 options to display something to every new connection, all defined in appropriate SRV file: Chat lines, small buttons (up to 30 with left, center, right aligned text), big buttons (max 5, always center aligned).
Examples:
UsersMotd=^1This is 1st chat line shown to everyone on connect
UsersMotd=+^7This is 2nd line, etc.
ButtnMotd=|^2First small button, text center-aligned
ButtnMotd=+<^4Second small button, text left-aligned
ButtnMotd=+>^6Third small button, text right-aligned
ConnectBtn=^1Welcome, first big button
ConnectBtn=+^3Take care or be banned
ConnectBtn=+^4Third big button...
All updates can be applied by !rld, you can check big buttons display by !conn, small buttons by !conns. I could also mention you may create several language versions of all messages (displayed in language chosen by the driver in preferences) and also use {NickName} parameter to be replaced by connecting player's nickname, but all this only in newer Airio version.
Last edited by EQ Worry, .
I've been in contact with Bunder, I tested his layouts and rotations. The strange thing was it was using wrong lap count, but on a different track/layout than in his case. I think I know why is this happening:
When you change track just by e.g. /track=au2, the track is loaded, but also one of the available layouts. I do not think I can prevent that. Only when new track (with random or first layout) is loaded, Airio can do /axload=newlayout. And I think that 1st random layout can change lap count.
The option should be to remove from server all layouts that are not used. Or I would need to update Airio code and send lap count only after the correct layout is loaded, but it will require some thinking and testing.
Hm, this seems like some different issue. While you can always downgrade to previous version, it would be much better to discover why this is happening. So if you'd like to go this way, please send me the rotation string and all layouts to eqworry [at] airio.eu. I'll do detailed testing then and hopefully identify the issue.
When you change track just by e.g. /track=au2, the track is loaded, but also one of the available layouts. I do not think I can prevent that. Only when new track (with random or first layout) is loaded, Airio can do /axload=newlayout. And I think that 1st random layout can change lap count.
The option should be to remove from server all layouts that are not used. Or I would need to update Airio code and send lap count only after the correct layout is loaded, but it will require some thinking and testing.
Hm, this seems like some different issue. While you can always downgrade to previous version, it would be much better to discover why this is happening. So if you'd like to go this way, please send me the rotation string and all layouts to eqworry [at] airio.eu. I'll do detailed testing then and hopefully identify the issue.
Always glad to help. Also any support is much appreciated. Being there, doing a few laps I think some info message explaining spectate after finish is necessary, simply EQW : SPECTATED AFTER FINISH, so that people know what happened to them. But I must add this myself to 2.3.4.
You also hinded on spectating people for too many penalties (cones hit). You still think it is a good idea? If so, I could add this setting/check to new version. But I have to say I was today very happy it is not implemented yet, because even if set to 30 objects I'm afraid I would not finish a single 2 lap circling. Doh....
Being there, doing a few laps I think some info message explaining spectate after finish is necessary, simply EQW : SPECTATED AFTER FINISH, so that people know what happened to them. But I must add this myself to 2.3.4.You also hinded on spectating people for too many penalties (cones hit). You still think it is a good idea? If so, I could add this setting/check to new version. But I have to say I was today very happy it is not implemented yet, because even if set to 30 objects I'm afraid I would not finish a single 2 lap circling. Doh....
I think it is an ommision/inconsistency. Either TC should not be configurable on track, only in pits (such as ABS is), or it should be part of player data with updates (such as auto gears are). As the TC is reported now, it really has no value, as it cannot be checked. And, btw, nice skins you do.
No idea for now, I'll contact you using PM here in forum, if you could send me the layouts and configs used, I could do detailed testing as hopefully see where's the catch...
Damn hard track, at least for me, and damn impossible lap/race times of everyone else. 
I guess it very much shows difference between people that can usually stay on track and that are really in full control of their car.
I'm of course happy to see Airio running there, I hope it will give good service to both admin and drivers. If you do not like something about the system, miss something or see something strange, just please let me know.
Also realize that you can turn off all messages by typing !silent. Detailed personal setting will be shown when you type !opt (same as Shift+i), not all are applicable to layout cruising though.
Good luck and see you around!
I guess it very much shows difference between people that can usually stay on track and that are really in full control of their car.I'm of course happy to see Airio running there, I hope it will give good service to both admin and drivers. If you do not like something about the system, miss something or see something strange, just please let me know.
Also realize that you can turn off all messages by typing !silent. Detailed personal setting will be shown when you type !opt (same as Shift+i), not all are applicable to layout cruising though.
Good luck and see you around!
No, that is not possible. Airio (and any other InSim application) can know only things reported by the LFS server and this does NOT include detailed car setup information, such as gear ratios, camber settings and such.
Only very general things are reported, in this case if automatic gear shifting is used. So in Airio you can prohibit (or require) auto gears, but that is all.
People were earlier asking if it is possible to enforce using some default car setup to have exactly equal cars in race. That is not possible either, for the same reason as above. The only car setup thing reported is if symmetric wheels are used, that's all.
This would require 2 things:
1) Direct support in Airio to send specific Web requests to a configurable address on various events (not just points, but some might require split/lap times, position and lots of other data, e.g. even PB improvements). Possible, sure, but hard to put it into some flexible framework and to select just what is sent and when.
2) Web script (PHP, ASP.NET) accepting the information on some server/site, processing them and showing somewhere or storing it for later display or whatever.
While it could be interesting, I think Remote and scripts processing Airio stats give a much wider view. Still, when some really interesting option appears, something like this may be implemented into Airio.
[Idea: Report race starts and finishers (with points), create tables showing nicely race numbers and results, one after another. That may be nice and usable, actually.
]Very weird indeed. The rotation code was not changed for some time already and I surely do not see where was 3 laps taken from. Please do some more experiments, see if really this happens only on this layout.
Hm, one (vague) idea. Isn't the 3 laps somehow hard-coded into that one particular layout? Airio first sets lap count and only then calls the track change, so if layouts can contain default lap count (not sure about this), maybe this one does?
Then the option would be either to update the lap count directly in layout or update Airio so that it sends race length (once again) after the layout is loaded... Let me know pls of any developement in this matter.
Now this is a real trouble and I'm very much afraid I cannot offer a simple solution. For some reason player/car setup data are reported via InSim by two different constructs.
One is "driver" data - autogears, brakehelp, autoclutch. Whenever some of this changes (e.g. by pressing Shift+G to tun on/off automatic gears while on track), it is reported as driver change and Airio can act based on these data when e.g. AG is prohibited.
The other is "car" data - ABS, TC, symmetric wheels. They are reported _only_ when joining track. While I believe you cannot turn on/off ABS while on track, if you manipulate with TC it is never directly reported, so it cannot be acted upon.
The only solution I see is asking periodically (say each 10 seconds) for all info concerning cars currently on track. Maybe this is possible, but I can say it is not easy, it may collide with other Airio checks and features. Anyway, because TC currently cannot be prohibited or enforced, as you very correctly noticed and reported, I'll try to adjust the code the way I hinted...
EDIT: The periodic TC check does not work either.
Server simply reports TC state active at the moment the driver joined track (as set on Brakes tab in Pits), regardless of current real state.Bottom line: In my opinion the valid TC on/off status is not reported anywhere and so in effect TC can be neither prohibited nor required. Of course I may have overlooked some option, in that case I'll be grateful for any ideas or comments. Meanwhile I'll add correct TC reporting as part of player (not car) data into my suggestions for InSim improvements to be implemented by LFS developers...
Last edited by EQ Worry, .
Yes, if using the LFSW data for free, you are limited to one request per 5 seconds, only then you can receive another set of data. The option is either to use the service as paid one or implement a buffer/queue that would allow sending requests only after 5 seconds.
Well, I would split the output by new line character and take 15th item. In C# it may basically look like this (I hope I don't have a bug there ):
):string host = pst.Split('\n')[14];FGED GREDG RDFGDR GSFDG